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A. introduction and Summary 

• The business of building satellites and space systems has matured. Few missions require, or can 
afford, excellent performance at any price. The new paradigm is doing more with less, providing 
quality systems at lower cost — in other words, doing our job “FasterBetterCheaper.” 

| The TRW Spacecraft COst REduction (SCORE) initiative was launched in 1990 by 
: Daniel S. Goldin, then general manager of TRW's Space & Technology Group. The SCORE 

mission is to apply continuous improvement (Cl) techniques to effect major reductions in the cost 
(our primary goal) and span time (as a corollary) required for the production of spacecraft. 

SCORE is a multiyear initiative that is having a profound effect on both procedural and cultural 
aspects of how we do business. And the objectives of this initiative are being realized. 

The focus of this paper is not on the results of SCORE per se, but rather on the things we have 
learned about how to do continuous improvement on a massive scale, with multilevel (hierarchical) 
Cl teams. The following sections summarize the chronology of the SCORE initiative, from team 
formation to development of the year-end report for 1991. Lessons learned, the core of this 
presentation, are discussed — with particular focus on the unique aspects of SCORE. 

The SCORE initiative is continuing and, as a part of our evolving culture, will never end. It has 
resulted in profound insights into the way we do work and (the topic at hand) how to do Cl for 
large and complex multidisciplinary development activities. 

B. SCORE TQM/CI Process Chronology 
B.l. Team Selection and Formation 

The SCORE team was a natural progression from the Cl efforts started in 1989 by a number of 
"grass roots" teams in our operating divisions. Teams were formed in small work areas to look at 
local processes and determine how they could be improved. These teams were largely unfunded, 
meeting during lunch hour or after work. One of the recurrent frustrations in these early efforts 
was that when a team got to the boundary of its functional specialty, the participants had difficulty 
determining how their processes interacted with those of other areas. SCORE was conceived to 
bridge this gap. 

The concept of SCORE is to employ a senior cross-functional team to look into all aspects of the 
process of designing, fabricating, assembling, and testing a generic spacecraft bus. The scope of 
the effort encompasses a bus project from authority to proceed (ATP) through launch of the first 
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satellite. Comprised of representatives from each of the organizations of Space & Technology 
Group involved in the processes under study, the team was formed in December 1990. Members 
were appointed by skill center managers from the Applied Technology Division (propulsion design 
and hardware), Engineering & Test Division (bus hardware design and spacecraft assembly/test), 
Electronic Systems Group Manufacturing Division, and the Space & Technology Group 
subcontracts and product assurance functions. Each member reported directly to the nominating 
manager and, in SCORE matters, spoke with his voice. All disciplines involved in the production 
of a spacecraft were represented: 

Program management 
Business and administration 
Mechanical engineering 
Control, sensors, and mechanisms 
Power systems and integration 
Spacecraft electronic systems 
Propulsion 

Manufacturing (including parts, materials, and processes) 

Propulsion 

Assembly, test, and launch 

Mechanical ground systems and environmental test 

Systems engineering 

Subcontracts 

Product integrity (quality assurance, reliability, producibility, maintainability, etc.) 

To assist in helping this large group interact effectively and function as a team instead of a 
committee, we included a full-time facilitator. The facilitator's tasks were to observe rather than 
participate in the team's activities, provide training in team techniques as needed, and make sure 
that we followed the rules we set. 

It was evident from the beginning that the team needed to establish norms of behavior, rules, and 
an operating philosophy. We jointly developed a set of rules, agreed to follow them, and posted 
the list prominently in the meeting room. As we progressed through 1991, we found that adhering 
to these rules helped significantly in achieving genuine teamwork. For example, the rules and 
operating philosophy require that team decisions be reached by consensus, not by simple majority. 
Decision by consensus promotes ownership by each team member. The rules further require that 
decisions be based upon data; this guideline helps members focus on process, not personal 
prejudice or emotion. 
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B.2. Team Training 

Each of the team members had individually participated in our CPI® Boot Camp, an orientation to 
the principles of process improvement, but there was no group training prior to team formation. 

To get us started, we were trained in the techniques of defining the “as-is,” could-be, and 
“should-be” process flows, then determining barriers to implementation. As the team progressed, 
we received “just-in-time” training specific to the task at hand. While generally following a classic 
process improvement flow, we did deviate when it made sense. For instance, some teams 
approach the “as-is” step by constructing a flow chart of every process involved to the lowest level 
of detail before further analysis. Because were trying to determine which processes had the 
greatest impact on the overall spacecraft process, we decided to define each process only in enough 
detail to be able to understand its impact on the whole. 

B.3. Methodology Selected 

The SCORE team employed a variety of TQM/CI tools and techniques in 1991, during a process 
that was largely one of discovery. We were determined to be driven by data instead of opinions. 
This commitment, coupled with the complex nature of modem spacecraft, led us to a hierarchical 
three-level teaming approach — and the use of a variety of tools, some quite successful and some 

less so. 

Process Flows and Maps 

Our first effort to define the total problem was based on detailed process flows. The SCORE team 
attempted to construct a comprehensive, detailed, cross-functional spacecraft process flow on a 
large wall (approximately 8 by 35 ft). After consuming several hours over a couple of meetings, it 
was apparent that this approach was futile. We concluded that another methodology was required. 

Definition of Levels 

Spacecraft development is by nature a multilevel process. We decided to emulate this hierarchy. 
Level 1 was defined as the total program, divided into time spans associated with major review 
milestones (e.g., ATP to PDR, PDR to CDR, etc.). The SCORE team became the Level 1 team. 
Level 2 was defined in accordance with major spacecraft development processes: requirements to 
design; mechanical design through manufacturing; electrical design through manufacturing; 
propulsion through manufacturing; assembly, integration, and test through on-orbit checkout; 
subcontracts; and program management. Level 3 was defined as the unit level. 

Seven key teams were formed (Figure 1) to address Level 2 processes. Each of these teams 
validated the Level 1 flow developed by SCORE, and developed Level 2 process flows, defining 
Level 3 subteams where they were needed (primarily in the design-through-manufacturing teams). 
Ultimately, the seven key teams formed 38 unit-level teams involving more than 250 employees. 
All teams were cross-functional, with representatives from systems engineering, subsystem 


*CPI is a registered trademark of Tatham Process Engineering Inc. 
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engineering, engineering specialties, design, integration and test, manufacturing, and 
subcontracts — as deemed appropriate by the Level 1 team. 

Data-Driven Approach 

The Level 2 teams defined process flows for the activities they addressed, with support from the 
related subteams. These flow diagrams (process definitions) were used to focus the collection of 
“as-is” data from selected existing and completed programs. The primary data collected and 
analyzed were cost (or man-hours of labor) and span time. Often it was necessary to modify the 
flows to better match the structure of data available from the programs. The quality (detail, 
documentation, definition, completeness) of data from the programs was a major hindrance, 
particularly when dealing with the “intellectual” phases of the programs (such as system 
engineering). 

Selecting High-Leverage Processes 

The need to focus on those processes having the highest leverage was apparent from the 
beginning. Our main tool in defining leverage was the Pareto diagram, with “as-is” cost the 
parameter addressed. This approach was applied with good success for those processes (design, 
integration and test, manufacturing) where the program data was relatively high in quality. 

Pareto diagrams were less successful for the requirements-to-design (RTD) processes. 
Discussions in Level 1 team meetings, supplemented by more formal techniques (Ishikawa 
diagrams coupled with multi-voting) made it apparent that many of the downstream (e.g., design) 
problems were related to the quality of RTD work — and that simply reducing the cost of RTD 
work could well lead to a higher total program cost. This investigation led to the definition of a 
major 1992 initiative focusing on the Integrated Development Process (IDP). 

Developing “Could-Be” and “Should-Be” Processes 

“Could-be” processes were developed first, and were defined as the best processes possible 
without constraints related to organization, facilities, etc.; in effect, the could-be processes 
represent a long-term goal. The “should-be” processes were less ambitious and realizable in the 
near-teim environment In some cases, the could-be and should-be processes were very close in 
terms of the key cost metric; in a few they were not The should-be processes were used to define 
attainable cost reductions, in terms of continuous improvement (Cl) factors. 

B.4. Summary of Results 

We collected data on 553 “as-is” processes and combined them into 383 processes for analysis. 
Through a combination of Pareto analysis and brainstorming, we identified high-leverage 
processes and performed cause-effect analyses upon them. We defined “should-be's” for 107 of 
the 383 processes and developed 1 12 specific recommendations for improvement. 
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C. SCORE Lessons Learned 


C.l. Team Composition and Commitment 

Team members were nominated by their skill center managers. The main selection criteria were a 
good knowledge of the work area and a desire to contribute to a process improvement effort. In 
general, those nominated volunteered for the assignment. Each team member was asked to commit 
a minimum of 16 hours a week to the SCORE effort and to agree to attend all of the SCORE 
meetings. 

C.2. Meeting Frequency and Timing 

We started with two 8-hour meetings per week. We quickly found that no more than 4 to 5 hours 
of that time were productive, and there was no time left for members to follow up on action items 
outside the meeting. After experimenting a bit, we settled on two 4-hour meetings a week. That 
seemed to be a good compromise and was our schedule for most of the year. As the Level 2 and 3 
team activities expanded, the core team meetings were cut to 2 hours twice a week, then to one 2- 
hour weekly meeting. When special issues arose, the meeting time was expanded to accommodate 
the need. 

C.3. Team Leadership and Culture 
Leadership 

Leading a team such as SCORE is different from managing a project. The members are expected 
to interact differently in a team setting. In a project setting there is a clear hierarchy understood by 
all; in a team setting, members are expected to contribute equally and to have their ideas considered 
equally without regard for rank, status, or position. 

Ideally, the leader acts as a coach. He must make sure that the group operates as a team rather than 
as a committee so that each member has a personal commitment to the result. For each problem 
encountered or issue addressed, the team must come up with its own answer. If the leader defines 
too de tail ed a plan for resolution, the members will fill in the blanks but not own the result. The 
leader also must be very careful to keep personal prejudices and preconceived solutions out of the 
process. To own the result, the team must develop it themselves. 

To get the maximum benefit from a process improvement team, one must set a dramatic goal as a 
challenge to creativity. Small (10 to 20 percent) improvements can usually be accomplished easily 
within the existing process framework. To achieve true breakthrough improvements (40 to 70 
percent), the goal must be seemingly unattainable. The leader must develop a personal vision of 
the goal and continually assert that it can be accomplished, then lead/nudge the team in the direction 
of the goal. 

Requiring that decisions on team activities be made by consensus seems at first to be abominably 
inefficient. Nonetheless, the object is to have all of the team members fully involved in decisions 
so that they can support the result with one voice. Therefore, discussions must be continued until 
everyone can agree or not strongly disagree with the result 
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It is imperative to have a clearly defined mission statement to focus upon, otherwise there is a 
tendency to wander. The statement need not be elaborate but must be sufficiently clear that you can 
tell when you have accomplished it The SCORE mission statement, for example, is short and to 
the point: 

The study is directed at a generic spacecraft flow. 

Define the “as-is” process flow (including cycle times) from authorization to proceed 
through on-orbit customer selloff. 

Determine high-leverage processes to investigate further. Develop a “should-be” overall 
process flow (including cycle times) applicable to a broad range of spacecrafts projects to: 
reduce cost and cycle time dramatically while maintaining or improving quality. 


It proved to be equally important to develop a set of meeting rules and require strict adherence to 
them. We had a practice from the beginning of developing a written agenda for the next meeting as 
one of the last items of business in every meeting. That was useful, but what we found was that 
we tended to belabor the earlier items and never get through the entire agenda. When we began to 
set a time limit for each agenda item, the situation improved somewhat. Finally, when we rigidly 
enforced the time limits even to the point of interrupting conversations in mid- word, we achieved 
our highest meeting effectiveness scores. It seems that the stress caused by dictatorially ending 
discussion was more than offset by the sense of accomplishment achieved by addressing all of the 
agenda items. 

Meeting effectiveness was measured for each meeting, then plotted and displayed in the meeting 
room. The measurement technique is simple and can be applied to any sort of meeting. At the end 
of the meeting, using a scale from 1 to 10, each member rates the Efficiency (how well the conduct 
of the meeting followed the rules) and the Importance (how important the meeting content is to 
him). All the E and I scores are averaged and multiplied together to produce an Effectiveness 
number. The Effectiveness can be dollarized to provide a measure of the “cost of lost opportunity” 
by subtracting the Effectiveness score from 1, then multiplying by the number of attendees, the 
length of the meeting, and an average cost per unit time for the attendees. It was interesting to note 
that the highest scores were achieved when the rules were most rigidly observed. It is therefore up 
to the leader to enforce the rules developed and adopted by the team. Demand excellence but 
realize that it can take many forms, and realize that schedule pressure to produce “something” 
offends the purist but results in helping to end “analysis paralysis.” 

Cultural Aspects 

We discovered early on that we are event (schedule) oriented, not process oriented. Furthermore, 
the detailed examples usually given of a Cl process are oriented toward short processes that repeat 
frequently, such as forms handling and high-rate manufacturing. It was difficult to relate these 
examples to the processes of requirements definition and detailed design. We ultimately settled 
upon a format for depicting our requirements and design processes in terms of a list of inputs, 
functions performed upon them, and a list of outputs. We are still inventing a way of viewing a 
lengthy spacecraft program in a process context. 
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The form, format, and conduct of the meeting are subtly critical to the outcome. There is a 
tendency for the meeting to become a project review where the leader, not the rest of the team, is 
presented with the pieces and expected to do the synthesis and make the final decision. We found 
this to be true after we launched the seven key teams mentioned above. Since all of the core team 
members could not attend every key team meeting, we added a “Key Team Leader Report” to the 
standing agenda. Each team leader was asked to share the progress of his team with the core team 
and was allocated a maximum of 5 minutes to do so. Within eight meetings, this agenda item 
became a de facto project review — with each team leader addressing the SCORE team leader, not 
the team, and feeling compelled to fill his time allocation whether or not he had anything to report. 
This behavior persisted even after I called attention to it numerous times. We solved the problem 
by eliminating the reporting agenda item and substituting one called “Issues. If a team leader had 
something to report to the team, he was required to write it on a white board before the meeting 
started. When we got to the issues item, we would vote on whether to address a given issue and 
set a time limit for its discussion. 

While generating a process flow or map, there is a strong tendency to focus on fixing individual 
problems immediately and to lose focus on the bigger picture. Giving in to this tendency leads to a 
“tiger team” approach and the effort falters. Our solution was to set aside a wall area in the meeting 
room and label it the “Should-Be Parking Lot.” As individual problems or non-value-added 
processes were found, they were listed on the parking lot to be addressed later when we 
progressed to the “should-be” development phase. 

In analyzing the “as-is” and developing improvements, there was a general perception that most of 
the barriers to performance are external to one's own area. Forcing the teams to be cross- 
functional helped to mitigate that perception. It also helped overcome the fact that we have 
organized ourselves into such narrowly defined specialities that it's hard for an individual to 
identify how his or her actions affect the final product. 

Having a few “nay-sayers” in the group improves the process by challenging the rest of the team. 
Nay-saying is often a way of talking out and defining a problem more clearly or at least defining 
the barriers to solution. 

A feeling of empowerment in the team members is developed by action and example, not by 
decree. It comes slowly and is the result of experiencing favorable response to success and 
tolerance of failure. 

C.4. Implications of Multiple Levels (Key Teams and Subteams) 

SCORE was unique in that it became a hierarchy of teams. The original concept was of a single 
team, but as we developed the Level 1 flow, it became apparent that more teams would be needed. 
With nearly 400 processes identified in the Level 1 flow, we formed seven key teams to study 
them in detail. The key team leaders were selected from the SCORE core team. Each of the teams 
was required to have cross-functional representation appropriate to its area of investigation. The 
task of the key teams was to validate the Level 1 flow developed by SCORE and define in more 
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detail the processes defined at Level 1. As the key teams formed and developed Level 2 process 
flows, they also found they had to create additional teams. 

In all, 38 unit or Level 3 teams were formed. As with the key teams, each unit team was required 
to have cross-functional representation. The unit-level teams studied the lowest level of detail in a 
process, usually involving one work area, and provided a natural conduit for grass roots team 
results to be considered in the context of the entire enterprise. 

The role of the core team changed as the additional teams were formed. We generated the Level 1 
flow as a team then changed into essentially a steering committee for the lower level teams, then 
became a team again to synthesize the results of the other teams. 

C.5. Tools and Techniques 

As mentioned above, we tried a variety of tools and techniques with varying degrees of success. 
We set out to construct the Level 1 flow as a classic flow chart and failed twice. Then we tried to 
construct an N 2 chart and failed. On the fourth attempt, we divided the task vertically into time 
slices defined by major program events, and horizontally by discipline or where work is 
performed. This time we succeeded and defined nearly 400 processes for further study. Figure 2 
shows an outline of the Level 1 flow. Within the horizontal lines, each team member constructed a 
flow of his work area as that discipline viewed it. Interfaces between disciplines were represented 
by connecting the source and destination points. Along the timeline, some events were put in 
quotation marks (e.g., “PDR”) to signify our awareness that when the program conducts a formal 
Preliminary Design Review, not all disciplines have reached the same level of design maturity. We 
used “PDR” to indicate a state of completion consistent with the classic definition of PDR. 

The Level 2 teams had difficulty with detailed flow charting as well. They developed a technique 
of defining a process in terms of inputs, operations performed on the inputs, and outputs. This 
method provided sufficient insight into the macro process to identify areas with the most leverage. 
The Electrical Design through Manufacturing key team discovered a significant benefit from this 
approach. When they began, they formed unit teams to study processes related to 16 different 
products. They were convinced that the products were unique and therefore the processes must be 
unique as well. When they reviewed the flows produced by the 16 unit teams, they discovered that 
the processes used to develop the 16 different products could be described by only seven different 
process flows! 

C.6. Networking with Other Cl Activities 

We made a conscious effort to learn from the experiences of other Cl teams. Several of the 
SCORE team were members of other teams in TRW Space & Technology Group and Electronic 
Systems Group and were able to bring “lessons learned” to our meetings. In spite of the good 
intentions of all concerned, however, we found that usually we didn't really understand until we 
had made the same mistake ourselves. 
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C.7. Follow-up: Acting on the Findings in a Continuous 

Improvement Environment 

For 1992, SCORE has begun to implement the suggestions derived from the 1991 work. We are 
sponsoring 16 implementation initiatives that touch most of the work areas. The largest of these 
efforts is the Integrated Developed Process (IDP) team, whose task is to define an IDP in our work 
environment that will result in a high level of design maturity and a physical configuration freeze at 
PDR. 

Our future plan is to implement new processes as opportunities occur and continue cause-effect 
analysis of additional processes. We will analyze the effect of the new or changed processes on 
the overall Level 1 flow and iterate until the goal is met 
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Design of structure, 
deployment mechanisms, 
and thermal control from 
ATP through manufacturing 
and delivery to A&T 


Design of electronic units, 
electro-mechanical 
devices, sensors, power 
systems, and onboard 
software from ATP through 
delivery to A&T 


Design, manufacture, 
assembly, and test of 
propulsion subsystems 
from ATP through delivery 
to A&T 


Assembly and test of 
spacecraft from receipt 
of units into stores 
through launch 


Figure 1* Seven Key Teams Addressed Level 2 Processes 
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Figure 2. Top-Level Process Flow Mapped Work Area Tasks Against Program Milestones 
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